Description

This PR make time parsing deterministic and explicitly validated. This will make accept only unambiguous formats, reject ambigous and engine-dependent strings and guard against accidnetal coercions from non-string inputs.

Date objects are always tricky to handle. It wouldn't be a big problem if we weren't receiving user input directly like we are now, but we'll never know what might happen later. (ref: https://jsdate.wtf/)

For example, the previous function implicitly trusted those strings and delegated parsing to the JS engine. That means:

• Engine/local/timezone dependencies for non-ISO formats and date-only strings
• Slient normalization (e.g., dates like 2023-02-29 rolling over to March 1)
  ...

Changes

Parsing Policy (normalized)

• Accepted inputs

  • ISO/RFC3339 datetimes with Z or explicit offset (±HH:MM)
  • Date-only (YYYY-MM-DD) -> interpreted as UTC midnight via Date.UTC to avoiding timezone drift
  • Numeric strings
    • Seconds if length is less than equal to 10
    • Otherwise, milliseconds
  • Date instance: getTime() (already UTC epoch ms)
  • number: epoch ms if finite and within representable range

• Rejected inputs

  • Ambiguous local datetime strings (e.g., "2024-01-15T10:30:00" with no Z/offset)
  • Non-string exotic types (boolean, function, symbol, bigint), arrays, and plain objects (blocked before any coercion)
  • Invalid calendar values (e.g., non-leap 2023-02-29)